早上出門前，你用手機 App 打開車門並啟動空調，這個看似簡單的動作，背後可能經過：

手機 App → 車廠雲端 → 行動網路 → 車載通訊控制單元
         → 車內閘道器 → 車身控制 ECU → 車門解鎖

這條路徑帶來便利，也帶來一連串問題：

• 發出指令的人真的是車主嗎？
• 指令在傳送途中可能被竄改或重送嗎？
• 雲端帳號失守後，攻擊者能控制一台車，還是一整批車？
• 對外連線的系統，能直接接觸控制車門或煞車的網路嗎？

汽車一旦接收外部資料，就不再是一座孤島，車聯網資安要保護的，正是資料從車外進入車內，經過系統間流動，最後影響真實世界的整條鏈。

這是「30 天實戰車聯網資安」的第一天，今天不急著分析封包，我們先建立一張全貌地圖。

今天的學習目標

讀完這篇文章，你應該能夠：

1. 解釋什麼是聯網車輛（Connected Vehicle）
2. 分辨車外生態系、車輛對外介面及車內網路
3. 說明 ECU／TCU／Gateway 的基本角色
4. 分清楚攻擊面、弱點及攻擊路徑
5. 對一項車聯網功能完成初步的攻擊面盤點

什麼是聯網車輛？

聯網車輛是能與車內裝置或車外系統交換資料的車輛，連線對象不只有網際網路，也包括其他車輛與道路設施，以及手機或維修設備等周邊與雲端服務。

美國交通部的 Connected Vehicle 教材，也將這個環境描述為車輛與行人裝置結合道路基礎設施，共同運作的通訊環境。參考：USDOT Connected Vehicle 教材

常見的 V2X（Vehicle-to-Everything）關係包括：

V2X 的目標之一，是讓道路使用者與基礎設施交換位置及速度，並傳遞道路事件等資訊，以提升環境感知能力。參考：USDOT V2X Communications

圖 1：聯網車輛可能同時透過感測器與車間網路，或經由路側設施及行動網路交換資料
圖片來源：Joelynn Schroeder／NLR U.S. Department of Energy

聯網車輛不等於自動駕駛車——一台車可以具備雲端服務或 V2X 通訊，卻沒有自動駕駛能力；自動駕駛車也可能同時利用聯網資訊，但兩者描述的是不同面向。

從車外到車內：先看懂三個區域

要理解攻擊面，可以先把整個系統分成三個區域：

圖 2：外部資料經由車輛對外介面與 Gateway 進入車內網路

這張圖最重要的不是元件名稱，而是兩條信任邊界（Trust Boundary）：

1. 外部資料進入車輛時，系統如何確認來源及內容，並檢查操作權限？
2. 資料從對外系統進入重要控制網路時，系統如何限制它能做的事？

連線本身不一定危險；真正需要分析的是，跨越信任邊界時有哪些檢查，以及檢查失效後能影響到哪裡。

ECU／TCU／Gateway 在做什麼？

ECU 之間需要交換資料才能協同運作，例如儀表板要顯示車速，必須取得其他控制單元提供的資料；車身控制系統也可能根據車速決定是否自動上鎖。

這些訊息會透過 CAN／LIN／FlexRay／Automotive Ethernet 等車載網路傳遞，各自的架構與頻寬不同，使用情境也不一樣，我們會在 Day 03 到 Day 06 逐步拆解。

今天先記住一句話：

車外介面不一定能直接控制車輛，但它可能成為通往車內系統的第一站。

攻擊面、弱點及攻擊路徑不一樣

這三個詞經常一起出現，但不能混為一談。

看見 Bluetooth、OBD-II 或 OTA，代表我們找到了需要檢查的攻擊面；只有確認存在可利用的缺陷，才可以說找到了弱點，接著還要證明攻擊者如何串起步驟，才能形成合理的攻擊路徑。

所以，攻擊面盤點不是漏洞宣判，而是提出接下來要驗證的問題。

聯網車輛有哪些常見攻擊面？

下圖把車輛周圍常見的有線與無線介面、感測系統及維修設備放在一起；要特別注意，圖中列出的是潛在入口，不代表這些介面本身一定存在可利用的弱點。

圖 3：現代車輛可能接觸的攻擊入口
圖片來源：Joelynn Schroeder／NLR U.S. Department of Energy

1. 實體與維修介面

• OBD-II 診斷接口
• USB 與外接儲存裝置
• 可直接接觸的 ECU、感測器及車載線路
• 維修與製造用測試設備

這類介面通常需要接近車輛，但仍可能擁有很高權限，分析時要問：接上設備後可以執行哪些診斷服務？是否需要驗證身分？權限是否會逾時？

2. 近距離無線介面

• Bluetooth
• Wi-Fi
• NFC
• 數位鑰匙使用的無線技術
• 胎壓監測等短距離無線系統

攻擊者不一定要進入車內，只要位於通訊範圍，就可能嘗試和系統互動，這裡要關心配對及認證，也要檢查訊息新鮮度與輸入資料的處理方式。

3. 遠端通訊介面

• Cellular 行動網路
• 車廠後端與手機 App API
• OTA 更新服務
• V2X 通訊
• 外部定位與地圖，以及交通資料

遠端介面的潛在影響範圍可能比單一車輛更大，因為共用後端與憑證，或共用軟體元件都可能同時服務整個車隊。

4. 後端／供應鏈／生命週期

• 第三方軟體與開源套件
• ECU 供應商與開發工具
• 雲端平台及管理帳號
• 憑證與金鑰管理、程式碼簽章流程
• 製造到維修、更新及報廢階段

汽車資安不只發生在車上，遭入侵的開發環境、有風險的第三方元件，或管理不當的更新簽章金鑰，都可能把問題帶進車輛。

NHTSA 的現代車輛資安最佳實務也強調風險導向與分層防護，並要求在車輛整個生命週期持續管理資安。參考：NHTSA Cybersecurity Best Practices for the Safety of Modern Vehicles（2022）

把入口一路追到真實世界的影響

只列出介面還不夠，一次初步分析至少要串起以下關係：

攻擊者 → 攻擊入口 → 可利用的弱點 → 攻擊路徑
       → 目標資產 → 損害情境 → 可能的風險處理

回到開頭的遠端開鎖功能，可以先提出一條假設路徑：

攻擊者取得使用者憑證
  → 通過雲端登入
  → 呼叫遠端控制 API
  → 後端將指令送至 TCU
  → Gateway 允許指令進入車身網路
  → 車門控制 ECU 執行解鎖

這個假設不代表任何特定車款真的存在漏洞，它的用途是協助我們找出驗證重點：

• 登入是否有多因素驗證與異常偵測？
• 遠端指令是否綁定車輛與使用者，並設定有效期限？
• 系統能否辨識被攔截後再次送出的舊指令？
• TCU 和 Gateway 是否只接受必要且已授權的操作？
• 車主能否看見異常操作紀錄並撤銷存取權？

這就是威脅分析的起點：不是先猜一個「駭客故事」，而是沿著真實的資料流與信任邊界，逐步確認假設。

車聯網資安究竟要保護什麼？

基本的資安目標仍可從 CIA 三要素開始，再加入真實性與授權，以及車聯網常見的訊息新鮮度需求。

Safety 則是另一個層次：它不是 CIA 旁邊的第四個資安屬性，而是資安事件可能造成的損害面向。

例如，偽造的 V2X 道路事件訊息可能沒有洩漏任何機密資料，卻可能讓接收車輛或駕駛做出錯誤判斷；也就是說，訊息的完整性與真實性，或訊息新鮮度失守，最後可能影響行車安全與營運，甚至帶來財務或隱私損害。

這個「資安屬性失效 → 造成損害 → 評估風險」的關係，會在 Day 24 到 Day 29 的 ISO/SAE 21434 與 TARA 再完整展開；ISO 將 ISO/SAE 21434 定位為道路車輛 E/E 系統的資安工程標準，涵蓋概念與開發，也延伸至生產後的營運維護及除役。參考：ISO/SAE 21434:2021

為什麼汽車資安特別棘手？

1. 使用年限長：車輛可能使用十年以上，維護責任遠比一般消費性裝置長
2. 供應鏈複雜：整車由 OEM 與不同層級供應商，以及軟體服務共同組成
3. 新舊技術並存：傳統車載協定會與 Ethernet、行動網路及雲端 API 同時存在
4. 即時與資源限制：防護措施不能任意破壞控制訊息的時序與可用性
5. 數位事件會產生實體後果：影響可能從資料外洩延伸到車輛功能及道路使用者
6. 規模效應明顯：共用元件或後端服務的問題可能影響整個車系或車隊

因此，汽車資安不能只依靠單一產品，它需要貫穿前期的安全架構與威脅分析，延伸到開發測試，再持續進行監控、事件回應及軟體更新，而且必須持續到車輛離開生產線之後。

這也是為什麼汽車產業逐漸以生命週期和風險管理的方式處理資安，除了工程標準 ISO/SAE 21434，UNECE UN R155 也從法規面要求適用範圍內的車廠建立 Cyber Security Management System（CSMS）並持續管理車輛資安風險。參考：UNECE UN Regulation No. 155

這 30 天會走過哪些路線？

本系列不是 30 篇彼此獨立的名詞介紹，而是一條逐步累積的實作路線：

車載電子架構與網路
        ↓
OBD-II／UDS／DoIP 診斷通訊
        ↓
V2X 車聯網通訊
        ↓
SUMO + OMNeT++ 交通與網路模擬
        ↓
CAN／V2X／OTA 攻擊面
        ↓
ISO/SAE 21434 與 TARA
        ↓
重現 V2X 假訊息情境並提出風險處理方案

到了 Day 30，我們會回到一座智慧十字路口：在 SUMO 建立道路與車流，在 OMNeT++ 建立 V2X 通訊，讓惡意節點送出假位置或假事件訊息，再觀察其影響並完成一次 TARA。

換句話說，今天畫下的第一張攻擊面地圖，最後會變成一份能夠模擬及驗證，並提出防護措施的完整案例。

今日實作：完成第一張攻擊面卡片

選擇一項你熟悉的功能：

• 手機 App 遠端開鎖
• OTA 軟體更新
• Bluetooth 音訊與通話
• OBD-II 車況讀取
• V2X 道路事件警示

接著填完這張卡片：

不需要在第一天就找到真正的漏洞，今天的合格成果，是畫出一條資料流，標出至少一個信任邊界與兩項資產，再提出三個值得驗證的問題。

先停在這裡，不要急著往下滑！
我完成的答案就在下方，建議先獨立填完自己的攻擊面卡片，再往下對照思考方式與遺漏的項目。

示範答案：手機 App 遠端開鎖

以下示範沿用文章開頭的遠端開鎖情境：

由這張卡片可以看出，真正需要保護的不只是「車門」，還包括帳號與控制權，以及訊息和操作紀錄；接下來可針對每項假設蒐集架構資料或設計測試，確認它是否真的構成弱點與攻擊路徑。

這份答案是教學用的概念示範，不代表任何特定車款存在上述弱點。

安全與法律提醒： 後續實作請使用模擬環境或測試台，或你已明確取得授權的設備；不要對道路上的真實車輛、他人的裝置或公共基礎設施進行測試。

今日重點

• 聯網車輛是由車輛與道路使用者、基礎設施及後端服務共同組成的系統
• ECU 負責車輛功能，TCU 提供對外通訊能力，Gateway 管理不同車載網路間的資料流
• 攻擊面不是漏洞；攻擊路徑則是從入口走到目標資產的一連串步驟
• 分析車聯網風險時，要沿著資料流找出信任邊界與目標資產，再評估可能損害
• Safety 是資安事件可能造成的影響面向，不是和 CIA 並列的資安屬性
• 車聯網資安必須涵蓋車輛的完整生命週期，而不是只保護某一條 CAN Bus

明日預告

知道車輛如何連向外部世界後，下一步要打開車內的黑盒子。

Day 02 將介紹 ECU／TCU／Gateway／Domain Controller／Central Computer，看看現代汽車的電子架構如何從大量分散式控制單元，逐步走向集中式運算。

延伸閱讀

• USDOT：Connected Vehicle 與 V2I 教材
• USDOT：Vehicle-to-Everything（V2X）Communications
• NHTSA：Cybersecurity Best Practices for the Safety of Modern Vehicles（2022）
• ISO：ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering
• UNECE：UN Regulation No. 155 — Cyber security and cyber security management system